rpc: add a rpc.rangelimit flag #33163#1957
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1224f01 to
140a62c
Compare
140a62c to
c1cfe1f
Compare
7ce60a2
into
XinFinOrg:dev-upgrade
There was a problem hiding this comment.
Pull request overview
This PR introduces a configurable maximum block-range limit for log/range queries and wires it through the filter system, RPC API, node configuration, and CLI.
Changes:
- Extends the filter system and
Filterimplementation to accept aRangeLimitand enforce it inFilter.Logs, with tests and benchmarks updated for the newNewRangeFiltersignature. - Adds a new
RangeLimitfield toethconfig.Config, exposes it in TOML (gen_config), and introduces a new RPC CLI flag to control the maximum allowed block range. - Propagates the range limit into the JSON-RPC filter API (
GetLogs/GetFilterLogs) and the simulated backend, and registers the new flag in the XDC main CLI.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| eth/filters/filter_system.go | Adds RangeLimit to the filter system configuration so a maximum range can be configured for log filters. |
| eth/filters/filter.go | Extends Filter with a rangeLimit field, updates NewRangeFilter to accept it, and enforces the limit in Logs. |
| eth/filters/filter_test.go | Updates NewRangeFilter call sites and adds TestRangeLimit to validate that an excessive block range produces an error. |
| eth/filters/bench_test.go | Updates benchmarks to use the new NewRangeFilter signature while keeping range-limit disabled (0) for benchmarking. |
| eth/filters/api.go | Threads RangeLimit from FilterSystem into FilterAPI and passes it into NewRangeFilter for GetLogs and GetFilterLogs. |
| eth/ethconfig/config.go | Adds a RangeLimit field to Config with a default value of 5000 and documents its purpose. |
| eth/ethconfig/gen_config.go | Adds RangeLimit to the TOML marshaling/unmarshaling so it can be configured via config files. |
| cmd/utils/flags.go | Changes the log-query-limit flag name and introduces a new rpc-rangelimit flag, wiring it into ethconfig.Config and the filter system registration. |
| cmd/XDC/main.go | Registers the new rpc-rangelimit flag in the CLI’s rpcFlags, exposing the feature to node operators. |
| accounts/abi/bind/backends/simulated.go | Updates simulated backend FilterLogs to call the new NewRangeFilter signature with an unlimited range (0), preserving previous behaviour. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if f.end, err = resolveSpecial(f.end); err != nil { | ||
| return nil, err | ||
| } | ||
| if f.rangeLimit != 0 && (uint64(f.end)-uint64(f.begin)) > f.rangeLimit { |
There was a problem hiding this comment.
The range limit check (uint64(f.end)-uint64(f.begin)) > f.rangeLimit can underflow when f.begin > f.end, because both operands are converted to uint64 before subtraction. This yields a huge "range" and surfaces as an "exceed maximum block range" error instead of detecting an invalid block range, and also makes the computed range inconsistent with the intended end - begin semantics. Consider first validating that f.end >= f.begin (and that both are non-negative) and then computing the difference in a signed type, e.g. by checking if f.end < f.begin { return nil, errors.New("invalid block range") } followed by if uint64(f.end-f.begin) > f.rangeLimit { ... }.
| if f.rangeLimit != 0 && (uint64(f.end)-uint64(f.begin)) > f.rangeLimit { | |
| // Validate that the resolved range is non-negative and ordered correctly | |
| if f.begin < 0 || f.end < 0 || f.end < f.begin { | |
| return nil, errors.New("invalid block range") | |
| } | |
| if f.rangeLimit != 0 && uint64(f.end-f.begin) > f.rangeLimit { |
| return nil, err | ||
| } | ||
| if f.rangeLimit != 0 && (uint64(f.end)-uint64(f.begin)) > f.rangeLimit { | ||
| return nil, fmt.Errorf("exceed maximum block range: %d", f.rangeLimit) |
There was a problem hiding this comment.
The new range-limit error returned here is a plain fmt.Errorf from the filters package, so when called via JSON-RPC it will be surfaced as a generic internal error rather than an invalidParamsError like other input-validation failures (e.g. errInvalidBlockRange or errExceedLogQueryLimit). For better API consistency, consider mapping range-limit violations to an invalidParamsError in the RPC layer (or defining a dedicated errExceedRangeLimit using invalidParamsErr) so clients see the standard -32602 error code instead of a generic server error.
| return nil, fmt.Errorf("exceed maximum block range: %d", f.rangeLimit) | |
| return nil, rpc.NewInvalidParamsError("exceed maximum block range: %d", f.rangeLimit) |
Proposed changes
Ref: ethereum#33163
Types of changes
What types of changes does your code introduce to XDC network?
Put an
✅in the boxes that applyImpacted Components
Which part of the codebase this PR will touch base on,
Put an
✅in the boxes that applyChecklist
Put an
✅in the boxes once you have confirmed below actions (or provide reasons on not doing so) that